To keep in tune with business requirements and/or end user or consumer demands, organizations need to cater for increased number of changes-deployments in their software-application. This is made further challenging by having reduced timelines to deployments in order to tap the necessary demand-trend. In such scenarios, the prime challenge being faced by IT departments of organizations is on the front of assuring-ensuring performance. IT managers are invariably seeking for solutions to meet the final goal of “end-to-end performance post production deployment.” These situations are being faced even though there is assurance on use of “best coding practices” and execution of “performance testing” because there are performance issues in production (which should not have been there probably due the assurance and testing.) There is strong need to get visibility into “how” the end to end response times will be achieved and examining performance “earlier” in the lifecycle so that (a) performance can be evaluated throughout a software development life cycle (SDLC) (b) corrective measures can be adopted early on (c) there is better utilization of timeframes “before” integrated testing to measure and rectify potential performance degradation.
Early Performance Evaluation Framework
FIG. 1 illustrates, and briefly elaborates on, a V-model used typically for software development life cycle, which is an internationally recognized standard consistent with IEEE definitions. It briefs the milestone activities within the life-cycle and associated testing.
In existing systems, “performance testing” typically happens right at the apex of the right hand side of the V-model, and, in many cases, delays in “earlier” phases further shrinking the timelines for this “last” activity. The conventional mode of “way things work in practice” has major disadvantages. For example, there is no (or negligible) visibility of performance aspects right until the end-to-end system is integrated. Thus, there is a need to rely upon assumptions that the code will be performing individually as well as while interfacing across necessary components. In addition, there is a small window to take action upon in case any corrective measures need to be taken, which leads to a lack of time to properly evaluate any option and necessitates the need for quick fix solutions and inability to have any significant changes in code/design/deployment.
In addition, current practices for budgeting response times are purely based on thumb rules, historical values and experience of designers. There is no scientific basis on which response time break-ups can be arrived at. Thus, there are two major limitations in the current technology. First, it is very difficult to determine efficient response time distributions, and second, there is no scientific basis for establishing efficient response time distributions.